I. Field of the Invention
The present invention generally relates to methods and systems for locking objects being maintained in an object-oriented system. More particularly, the present invention relates to providing a database lock for an object maintained in transient memory and managing the lock based on the status of a nested logical unit of work affecting the object.
II. Background Information
Applications maintaining an internal state in transient memory are known in the art. Operations, which may have the effect of changing an application's state, may be performed in transient memory, such as in an object instance opened on a buffer. Frequently, to accomplish a desired task, it is necessary to perform a group of potentially state-changing operations. The nature of the task may be such that it is desirable that if one or more of the operations fails, none of the state changes caused by the group of operations take effect.
In order to address this concern, logical units of work (LUW) are provided in the art. An LUW is an inseparable set of operations that must be executed in their entirety or not at all. Although LUWs are commonly known in the art as a set of database operations, an LUW may also be opened in a buffer to group together a set of buffered operations affecting application state.
For example, an application operative to effect a money transfer from a checking account to a savings account may execute a number of operations to fully accomplish a transfer, including: (1) removing funds from the checking account; (2) adding funds to the savings account; and (3) generating a record of the transaction. While each of these steps may be carried out separately, it is desirable to tie them together such that if one fails, none of the changes are implemented. In this manner, it is possible to avoid a scenario in which the system successfully removes funds from the checking account (operation 1) but for some reason, such as loss of power to the system, fails to effect the addition of funds to the savings account (operation 2), leaving the account holder with a net loss of funds.
LUWs generally conclude with either a “rollback” or “commit” statement. If the LUW is rolled back, none of the operations comprising the LUW take effect and the application is returned to its initial state—the state existing prior to execution of any of the operations comprising the LUW. By committing an LUW, the changes made to the state of the application by the operations contained therein are made accepted, and the application state existing prior to performing the LUW operations is discarded, meaning the application state may no longer be rolled back.
In certain instances, one or more operations of an LUW may comprise a set of sub-operations that desirably execute or fail as a whole. In such cases, it may be desirable to treat the sub-operations as an inner LUW within the outer, original LUW. A group of LUWs comprising an outer LUW and at least one inner LUW may be termed a “nested” LUW. Similar to the operation of a single LUW, if a single sub-operation of an inner LUW fails, the inner LUW will roll back to the application state existing prior to execution of the sub-operations comprising the inner LUW. However, rolling the inner LUW back will not roll the application back to the state existing prior to execution of the outer LUW.
Often, state-holding entities, such as buffered objects or locking mechanisms, are interested in the status of LUW operations and/or the application state resulting from LUW operations. However, typical LUW managers are not operative to ensure that interested entities are made aware of events relating to LUW operations. This inability to facilitate awareness of LUW events may have negative consequences. For example, an interested object not aware of state changes caused by LUW operations may present inconsistent data. Similarly, a locking mechanism placing a lock on an object affected by LUW operations may inadvertently leave the lock in place after the LUW is committed, preventing access to the object after the need for the lock has dissipated.
In object-oriented systems, it is common for more than one application or user to have concurrent access to an object. Naturally, in concurrent systems, it is desirable to ensure that a consistent view of the object is provided to every requesting application or user. In an effort to ensure consistency of the object view provided to requesting applications, it is known in the art to issue locks on objects that are checked out to a requesting application. Two common types of locks are (i) exclusive locks; and (ii) shared locks. An exclusive lock allows the requesting application to change the state of the object and prevents other application from changing the object state. Generally, only one exclusive lock at a time may be placed on a particular object. Conversely, multiple shared locks may be placed on an object. A shared lock allows the requesting application to read an object, but does not allow the requesting application or any other application to change the state of the object.
While lock mechanisms are operative to place a database lock on an object being maintained by an application in transient memory, such mechanisms are typically not suited to ensure consistency in systems performing nested LUWs in transient memory rather than on the database. The inability of a locking mechanism to properly manage locks in nested LUWs may result in a lock remaining on an object after that object has been released by the application that requested the lock. As a result, a later-requesting application may be incorrectly prohibited from changing the state of the object.